When developing applications for computer system implementation, such as within a client-server computer network, developers must make system calls to the file system of an underlying operating system with which they are working. Such system calls to the operating system file structure may comprise calls to manipulate the operating system's directory structure or to open an individual file. These system calls must adhere to an operating system recognized specification, including the file path and the file name of the content that is being requested by the call. The underlying operating system's application program interfaces (“APIs”) typically only handle pre-defined types of system calls and query strings. For example, standard operating system APIs can typically only process ASCII (American Standard Code for Information Interchange) encoded data as parameters to system calls.
The default encoding implementation in most system libraries is pure ASCII, and only recently have changes been made, for example, to the Microsoft Windows and standard Unix APIs to accept non-ASCII characters in a file specification. However, in the Windows environment, the use of non-ASCII characters in a file specification requires a separate API (a separate function call). Thus, to pass a non-ASCII file specification to a Windows system, a developer must make an additional and completely different function call than that used for ASCII characters.
Non-ASCII encoding specifications are often categorized under the heading of Unicode. Unicode methods are function calls within an operating system API that allow the API to accept Unicode character specifications, as opposed to ASCII character specifications. Operating systems process Unicode calls in a variety of different manners. For example, in Unix, the function calls for ASCII and Unicode character specifications are the same, and Unix can accept, for example, a UTF-8 encoded string rather than just an ASCII string. “UTF-8” stands for UCS Transformation Format, 8-bit, and “UCS” stands for Universal Character Set. UCS is an explicit name for the character specifications typically called Unicode. Thus, UTF-8 encoding is basically an 8-bit transmission format for Unicode. The ASCII specification is also an eight bit format, though characters employing the 8th (“high-order”) bit are often known as “extended ASCII” characters.
In some operating systems, such as Unix, it is thus easier than in others, such as Windows, to make non-ASCII character specification functions calls. This is because, for example, in Unix, the same function call can be made for a non-ASCII Unicode character specification as for an ASCII character specification, and the query string is automatically transformed to UTF-8 encoding. In Windows, on the other hand, the actual file specification must be encoded separately into a Unicode encoding, such as UCS-2 (Universal Character Set 2-byte), and a different function call must be made. Thus, in cross-platform development environments, developers must typically explicitly code their applications to deal with the problems associated with passing non-ASCII file specifications to an operating system's file system. In prior art cross-platform application development systems and methods, developers typically have to write programmatically wrapped code that will execute differently (different calls will be made) depending on whether the developer is building an application for, for example, a Windows environment, or for a Unix environment, or other operating system environment. The result of these prior art methods and systems is that developers end up duplicating their efforts by writing cluttered code with split functionality to ensure that file system function calls will execute properly for each operating system environment they expect to encounter. The resulting application code can be lengthy, duplicative, and thus, inefficient.
A developer's programmatic interface to an operating system's file space must thus be able to handle non-ASCII file specifications in a cross-platform development environment. The file path (absolute or relative), including the directory hierarchy and the leaf node file name itself, can be non-ASCII, and thus there must be a means in place for handling non-ASCII file specifications. Currently, the encoding of non-ASCII file specifications and the encoding capabilities of the underlying file system API (at the operating system level) must be handled programmatically by the developer. Each operating system maintains different encoding interfaces for file system interaction, forcing developers to make operating system appropriate function calls when interacting with that operating system's file space. This results in unwieldy, cluttered and unnecessarily duplicative and complicated code writing for developers.